Azhar Khan · Utilities Data Platform Map · Agentic AI Deployment
UTILITY BILL PAY · AGENTIC SYSTEM← Back

Check the account before the exception.

Each of 700,000 bills a month is read against the account’s payment and usage state before any exception.

invoices a month
vendors
layouts
capture accuracy
accounts
01 · INTAKE Bills arrive. PDF · EDI · API · email 02 · CLASSIFY 300+ layouts. model routes each bill to its template 03 · EXTRACT 190 fields. 48 charge lines · 8 services · 9 meters 04 · VALIDATE Account check first. reconciled before flagged 05 · RECONCILE One identity per site and meter. collated state view 06 · APPROVE 1 in 100 reaches a person 07 · POST Payable created. payment scheduled · matched to the record 08 · PAY $2.5B a year. cleared · posted · reconciled
  • 01 · INTAKEBills arrive.PDF · EDI · API · email
  • 02 · CLASSIFY300+ layouts.model routes each bill to its template
  • 03 · EXTRACT190 fields.48 charge lines · 8 services · 9 meters
  • 04 · VALIDATEAccount check first.reconciled before flagged
  • 05 · RECONCILEOne identity per site and meter.collated state view
  • 06 · APPROVE1 in 100 reaches a person
  • 07 · POSTPayable created.payment scheduled · matched to the record
  • 08 · PAY$2.5B a year.cleared · posted · reconciled

With the account checked first, exceptions fell from half the volume to 1 in 100.

← UtilitiesHome →Microsoft case study →Resume →

A back office became a buying desk.

I directed the layer where every data product, the payment run included, reads the same record.

LAYERS
03 AGENTIC ORCHESTRATION · UTILITY BILL PAY · DATA LAYER A BUYING DESK DATAone source of truth IDENTITYevery action has a name OBSERVABILITYevery run is traced EXCEPTIONSeach failure carries its evidence GOVERNANCEa person approves, corrects or escalates each exception EXECUTION TRACES · OBSERVABILITY Each decision logs its path, outcome and error, and the log feeds the evals and the error catalog. TRACES ON TOP ONTOLOGY BUSINESS ONTOLOGY what a bill, a vendor, a site, a meter, and a decision mean, and how they connect TECHNICAL ONTOLOGY which system holds what, with vendor, site and meter reconciled across the source systems ONTOLOGY UNDERNEATH every job and model → traces INTAKE · CAPTURE → EXTRACTION EDI feeds Portal harvest Mail and scan Meter data Layout classify Field extraction THE DIGITAL TWIN the modeled operation, every bill, meter and site reconciled Normalizeruns autonomously Reconcileruns autonomously ML Forecastapplied ML THE RECONCILED RECORDvendor, site and meter on one identity DATA PRODUCTS · read from the reconciled record BENCHMARKING · savings ranked Manager acts FORECASTS · ACCRUALS Controller Posted BILL AUDIT → PAYMENT the payment run reads the same record Payment CARBON · SCOPE 1 · 2 Report BUDGET · ACTUAL To owner INTELLIGENCE LOOP · actuals and outcomes refit the model sharper forecasts → the twin actual · forecast variance signal model refit · eval gate forecast → twin A record that will not reconcile is held. Each failure is typed as business, system or model in the error catalog. OUTSIDE THE LAYER · the residual invoices no layout matches yet · spreadsheet reconciliation · the manual tail concentrates here THE DATA LAYER · every field and meter on one record IN BRIEF EDI, portal harvest, mail and scan, and meter data land on one queue. Capture across 300+ layouts went from 65% to 99%. The twin normalizes and reconciles every bill, and a record that will not reconcile is held for a person. Benchmarking, forecasts and accruals, carbon, and budget against actual read the same record as the payment run. 1 invoice in 100 reaches a person. 290 keyers became 65 analysts. runs autonomously human-in-the-loop the digital twin applied ML intelligence loop exception feed Live deployment · governed data layer

HOVER OR TAP ANY NODE FOR WHAT IT DOES · SCROLL OR SWIPE SIDEWAYS TO PAN · 1 INVOICE IN 100 REACHES A PERSON